In a DSLAM system and other data transfer systems, data may be sent from a higher-speed or higher-capacity data source to a large number (potentially thousands) of lower-capacity destinations. In some systems, a traffic manager is responsible for distributing this data to destinations across a shared communication channel, such as a shared data bus. In some types of systems, each destination can have wide ranging data rates (for example, ranging from about 23 Kbps to about 52 Mbps) and data rates for some destinations can change during transmission (e.g., in real time). Such a large number and varying data rates of destinations present challenges in attempting to schedule data both efficiently and fairly, particularly if it is desired to avoid greatly increasing hardware size and power.
In DSLAMs and similar systems, some architectures require per port transmission FIFO's, which can be costly to implement in terms of power and size.
One proposed solution in ATM and other systems is to shape downstream traffic on a per destination such as a per port basis. In this application, the terms port and ports will be understood to constitute any appropriate data destination unless the context specifically requires otherwise. Such a per port shaping function, shapes aggregate traffic to each loop port's actual data rate, thus eliminating the need for any further scheduling. However, solutions using per port traffic shaping often must adjust the shaping rate in real time each time the loop port changes rates. Due to the latency between the loop port data rate changing and the traffic shaper rate changing, there must be a mechanism to ensure the PHY buffer (e.g., the physical interface buffer) in the loop port is not overflowed. To do this the shaper rate must be less then the actual loop port rate since the two rates are not synchronized. The rate difference represents a loss in throughput bandwidth.
Another solution in ATM-type systems is to extend the UTOPIA Level 2 (UL2) standard to support a large number of ports. This involves polling all ports, collecting and prioritizing their responses, and then sending data to the selected loop port. Solutions that try to extend the current UL2 standard can suffer from one or more limitations, such as, (1) There is no inherent mechanism for port weighting. All ports would have to be polled at a rate to satisfy the fastest loop port. (2) UL2 is not intended to support aggregate port bandwidth greater then the UL2 bus bandwidth. (3) The UL2 standard supports 31 ports; to scale UL2 to a large number of ports generally would require more polling bandwidth and additional pins. For example, scaling linearly for 2 k loop ports results in 64 poll status pins carrying very little useful information.
Prior Patents and Publications or Other Relevant Materials
The following patents and publications may be related to the invention or provide background information. Listing of these references here should not be taken to indicate that any formal search has been completed or that any of these references constitute prior art. References include:                Transwitch Cubit based DSLAM design        Motorola 860SAR based DSLAM design        IgT WAC-185/186/187/188 based DSLAM design        PMC-980448, ATM Traffic Manager Device Telecom Standard Product Engineering Document        PMC-980929, APEX Loop Port Scheduler        